I really hate it when I overlook something. This week it was libgda, which is the current backend for DBDO. It was after a few commits by the pecl team to the config.w32 file in cvs. The question came to me.... Could DBDO actually be built on windows?
Unfortunatly after some reseach, the answer was a definate maybe. libgda was designed to be buildable on windows, but no-one has really taken up the gauntlet and run with it. Browsing through the archives, it looks like a few people have tried, but no-one had actually decided to make it their baby. So no dll's or lib's exist for libgda.
This does leave DBDO in a bit of a state of flux.
- Should I continue on, as on Unix, libgda provides an excellent backend, and builds really easily and quickly. (on the offchance that someone gets passionate about win32 support and spend a few nights figuring out how to build libgda)
- Should I look at the alternative backends:
- libdbi - which lacks
- has no global connection/config cache
- a schema retreival API
- a column type to abstract column type API
- pdo - which lacks
- has no global connection/config cache
- a schema retreival API
- a column type to abstract column type API
- copy & pasting chunks of libgda (impossible due to the LGPL...), let alone a pain to implement..
To implement the same thing using PDO, would require
- copying the driver header file (and keeping up with any changes)
- copying the driver loader code.
- implementing a config cache.
- implementing a connection cache.
- adding schema query and fetchers for all the backends.
- adding schema type to enum type mappers.
- enriching the type enum? maybe
It may be worth attempting this by emulating the gda calls, and relaying them through the pdo backends??
On a side note, It became clear earlier that the joinAdd design in DataObjects is probably far better done on the client side, - most of it relates to building the join part based on the links configuration. As far as I can see, this is hardly touches on the special advantages of coding it up in C.
